1. Field of the Invention
The present invention relates to an apparatus for aiding debugging an application task by fetching system call data including a return address to an application task, the task name that issued the system call, the type of the system call, and the parameters of the system call, when the system call is issued to request an operating system (OS) service.
2. Description of the Related Art
FIG. 1 is a simplified block diagram showing the configuration of a computer equipped with a debugging aid apparatus by fetching system call data. In the figure, the numeral 200 indicates a keyboard from which data is given to a CPU 101 via an I/O 103, and the CPU 101 stores the data into a memory 102.
FIG. 2 is a diagram showing the software configuration of a computer equipped with a debugging aid apparatus according to the prior art. In the example shown, when a system call is issued, or when an error occurs during the execution of a system call instruction, system call data (including error data in the case of an error occurrence) is stored into a table 9 (for example, a ring buffer) in the memory 102. In response to an external request entered from the keyboard 200, system call data display means 11 displays the contents of the table 9 on a display 300.
In FIG. 2, the numeral 7 designates an OS (operating system, particularly the kernel), which includes: a supervisor 71 that user programs use as a means of requesting the services of the OS 7; a memory management routine 72 for managing the memory 102; a data management routine 73 for data management; a process management routine 74 for managing the execution of jobs and processes; and an input/output, management routine 75 for the input/output management of input/output devices. When a system call is issued, or when an interrupt occurs, the OS 7 saves the contents of registers on a stack (not shown), and pushes a return address to an application task onto the top of these data upon completion of the interrupt process. First return-address fetch means 8 fetches from the stack the return address to the application task 6 pushed onto the top of the stack when the system call is issued, while second return-address fetch means 10 fetches from the stack the return address to the application task 6 pushed onto the top of the stack when the interrupt occurs. The fetched return address is stored into the table 9 in the memory 102.
FIG. 3 is a flowchart of the operation performed in the prior art computer with the debugging aid apparatus when an application task requests a service of the OS 7.
First, a system call is issued from the application task 6 (ST51). When the system call is issued, the return address to the application task 6 pushed onto the top of the stack is fetched (ST52). The fetched address is stored into the table 9 in the memory 102 (ST53). Then, control is passed to the supervisor 71 (ST54), and the supervisor 71 interprets the system call instruction (ST55).
Next, system call data including the task name that issued the system call, the type of the system call, the parameters of the system call, etc. is stored into the table 9 (ST56). That is, the system call data is added onto the return address to the application task 6 already stored in the table 9. Finally, the; supervisor 71 passes control to the memory management routine 72, the data management routine 73, the process management routine 74, and the input/output management routine 75, to execute the instruction (ST57).
A processing procedure when an interrupt to request a service of the OS 7 occurs will be described below with reference to the flowchart of FIG. 4.
When an interrupt is requested (ST61), the return address stored at the top of the stack is fetched (ST62). The fetched address is stored into the table 9 (ST63), and control is passed to the supervisor 71 (ST64). The supervisor 71 analyzes the type of the interruption (ST65), and stores data of the interruption, such as the type of interrupt, the interrupted task name, etc., into the table 9 (ST66). The supervisor 71 passes control to the memory management routine 72, the data management routine 73, the process management routine 74, and the input/output management routine 75, to service the interrupt (ST67)
When the application task 6 requests a service of the OS 7 and, executes a system call instruction or interrupt instruction if an error occurs, the processing performed is substantially the same as in the above-described interrupt. For example, when an error occurs during the execution of a system call instruction, the processions shown in a flowchart of FIG. 5 is performed.
First, current error data (an address at which the error occurred, a task that caused the error) are fetched (ST72), and then, the error data are added on the top of the return address of the application task 6 already stored in the table 9 in the memory 102 (ST73). In this manner, the system call data including the error data are stored in the table 9 in the memory 102. When displaying the system call data at a user's request, the system call data display means 11 searches the table 9 and displays the necessary contents.
When the user desires to display the error data, the user enters, for example, a command "show error" from the keyboard 200. In response, the task name that caused the error, the address at which the error occurred, and the address in the application task 6 from which issued the system call, are displayed on the display 300. When displaying the system call issuing situation of the application task 6, the user enters a command "show application-name", for example, from the keyboard 200. In response, the system call data display means 11 displays the type of the issued system call, the parameters of the system call, the system call issuing address of the application task, etc. on the display 300.
FIG. 6 shows an example of a program for issuing a system call to the OS 7 having an assembler interface. As shown, the system call instruction consists or a set of instructions for setting the system call function codes and parameters into respective registers, followed by a software interrupt instruction (trap).
FIG. 7 is a diagram showing the flow of processing performed when the application task 6 written in a high-level language issues a system call through a high-level language interface routine 12. In FIG. 7, the system call issued from the application task 6 calls the supervisor 71 through the high-level language interface routine 12 which converts the application task of the high-level language into executable codes on the computer. In this case, the first return-address fetch means 8 fetches the address of the high-level language interface routine 12, not the system call issuing address of the application task 6, and stores the fetched address into the table 102.
As described, in the computer with the debugging aid apparatus of the prior art, since the system call issued from the application task 6 written in a high-level language calls the supervisor 71 through the high-level language interface routine 12, the address that the first return-address fetch means 8 fetches as the system call issuing address is always the address of the high-level language interface routine 12. In other words, when a system call is issued from one of the application tasks 6, it is not possible to identify the application task 6 that issued the system call, by referencing the address that was fetched by the first return-address fetch means 8 and stored in the table 9. This causes a problem in debugging, when analyzing an error caused by the application task 6 during the execution of the OS 7 service or processing.